nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Teamsite and .net coexist?

nico

So we are moving from old asp to .net, have any of you made the move and if so what is needed to get Teamsite playing ok with .aspx pages etc?

Of course I assume you'll need to install the .net framework on the Teamsite server, in our case ts6.5sp1 then tell iis to display .aspx pages.

What if our developers use a vss source control system, will we need to import objects/dll's into teamsite for page rendering?

Dumb question but does templating and previewing pages still work with aspx pages in Teamsite? What if our developers are doing "code behind" development? Does the .aspx page become the tpl and does the dependant .cs file have to be in the "presentation" directory?

I've mentioned that I have not seen one blurb by Interwoven to address this integration and I would really really appreciate if they did so. I sure would hate to be forced out of using IW for MS CMS.

Thanks,
Nico

Find more posts tagged with

Comments

JonathonG

We have done virtualization of .NET pages in TeamSite. Basically, you need to configure IIS to see the workarea root as an application. Then, you put everything (code behinds, dlls, etc.) in their location relative to the application root in the workarea. We had the .net developers upload the most recent "stable" versions of their work products to TeamSite so that content authors were working with the best set of presentation code. As for templating, yeah, you take an .aspx file and make it a .tpl. We didn't have to put the .cs file anywhere specifically. I can't remember exactly how we made preview work, but I think we used some special logic in the tpl to change the path reference on the .cs file if we were in preview mode.

Gregg Faus

Integration with ASP.net 2.0 is even more of a challenge. Specifically how previews and include file references work. Since our preview directory is outside of the application root, our include references do not work properly. Our workarea structure is as follows:
/web/ (All production web files, app space created in IIS)
/web/include/ (Include files here)
/templatedata/ (Templating files)
/templatedata/preview/ (Preview directory)

I had to create app space on my preview directory and copy over the include directory in order for it work correctly. Both applications were configured to run ASP.net 2.0 as well. I tried messing around with the ISAPI filter plugin, but I couldn't configure it to correctly to remap my include references to the /web/include/ directory.

User controls were a pain to get to work in preview mode. I had to comment out the control directive and put static content in place of the dynamically rendered control content. Again, all due to how your app space is set up. I would guess if you had your templatedata directory within your website files you'd be fine. I just find that to be a bad practice.

ASP.net 1.x is much more forgiving for include file references. From a previous post of mine, I did find a workaround.

Good luck.

GRD

You can specify the preview folder for each template in templating.cfg; we typically use a folder named /htdocs/zz_temp_preview where /htdocs is an ASP.NET 2.0-enabled IIS application. The only real pain is that the /htdocs folder in each workarea, edition and staging also needs to be an IIS application in order for preview to work. Other than that it's pretty clean.

We also have been using the ASP.NET 2.0 master page paradigm, where the /htdocs/master/page folder contains all the master pages and the TeamSite-generated pages are just children with tags.

Another neat trick is to encapsulate all your non-core stuff into user controls, placed in a particular folder (usually /htdocs/uc for us). In your DCT, use a callout to a perl script to return the available user controls as a dropdown. Then, using code in the PT, create the necessary ASP.NET references to load that particular control at runtime. You can isolate forms, grids, or whatever and still use a generic TeamSite DCT. It's a good way to cut down on the number of DCT's and segment off your ASP.NET development efforts using folder-level permissions.

-Greg