What I'm Doing
I have an ASP.Net Web Application and a WiX Setup Project in Visual Studio 2010. I can explicitly harvest the web application with the following HEAT command set as a pre-build event for the setup project:
“%WIX%\bin\heat.exe” project "$(SolutionDir)Application.WebUI\Application.WebUI.vbproj" -o "$(ProjectDir)ProjectOutputContent.wxs" -pog Content -ag -template fragment -nologo -directoryid RUNTIMEFOLDER
“%WIX%\bin\heat.exe” project "$(SolutionDir)Application.WebUI\Application.WebUI.vbproj" -o "$(ProjectDir)ProjectOutputBinariesAndSymbols.wxs" -pog Binaries -pog Symbols -ag -template fragment -nologo -directoryid BINFOLDER
Keep in mind that RUNTIME folder and BINFOLDER are directories I declaratively setup in my main product WXS file.
Why I Don't Like It
This approach is annoying because I need the HEAT generated fragment WXS files checked out before I can build the setup project. Another consideration is that it is a web application and I need to drop the binaries and symbols into a different directory (bin) than the content.
What I'm Aiming For
I would rather use a project reference within the Wix Setup Project and simply set the Harvest property to True. I could then harvest the BinariesContentSatellites to get the items I need in my fragment and then set a single Directory Id that I can reference in the main product WXS. The problem is that this will put the content, binaries and symbols in the same folder where I need the latter two in a nested bin folder. I can't add this project reference twice, each with different harvest options.
My Question
Is there a way to do what I'm after or do I need to keep with the pre-build event? As an aside, I have considered manually harvesting the fragment once, without a build event, and then re-harvesting as needed. I would prefer to avoid that approach.
Answering your topic "Why I Don't Like It" : I too had same problem but then i found the solution. You dont need to check-in the fragment file. Just add the file physically and then include in your project
Note : Don't add the fragment file from the project.
Related
I have a complete ASP.NET project and am now trying to use automatic testing methods to test the code.
So, I have calls to methods which use configurationManager to call settings from Web.config for things like API keys etc..
My question is, it possible to synchronise my app.config for my test project and my web.config, so that if I update either one of them it takes effect on both projects, or will I have to do something different?
I have currently just copied what I need from the web.config, but because I work for a website we always have changing variables and I can't guarantee that if we change one that my colleagues will remember to update the corresponding key in both projects.
In the unit test project properties, you can add a pre-build step to copy the main web.config to the unit test project, overwriting the existing unit test project config file. This will do the same as you do now manually, but gaurantees the two config files will be in sync.
Alternatively, and perhaps better, delete the existing unit test config file (and exclude from the project) the click 'Add Existing Item' within the unit test project, choose the main project config file, and select 'Add As Link' instead of 'Add' (click the right hand edge of the 'add' button to achieve this). There will only be one config file on your disc, but both projects will use it.
I'm trying to build a redistributable assembly containing several custom controls (CommonControls).
My environment: MSVC 2010, ASP.NET (WebForms) .NET 2.0/3.0/3.5
The problem: Compiling everything with a Web Deployment Project won't work if I localize CommonControls via App_GlobalResources.
Here is how I build the CommonControls assembly:
I use a WebSite containing the .ascx and .ascx.cs files:
and a Web Deployment Project with the following settings:
This will create "CommonControls.dll".
That assembly is to be used in a different ASP.NET WebApplication as follows:
web.config:
First (minor) problem: Adding CommonControls as a dependency will not automatically copy the satellite assemblies for the languages. Copying them manually to the correct output path seems to work though (for DEBUGGING).
Main problem: The Main web application is also localized via App_GlobalResources and built with a Web Deployment Project:
That build process will fail with
ASPNETCOMPILER : error ASPRUNTIME: Object reference not set to an
instance of an object.
Both deployment projects create a file named "bin\App_GlobalResources.compiled" and I guess those 2 files cannot coexist peacefully within the same output-project.
Is there any elegant solution to localize both CommonContols AND Main using ASP.NET built-in localization?
Note: The project I'm working on has to be compatible with Apache+Mono, so my project-settings (screenshots above) must be exactly like this to work correctly (already tested all other variations).
I fixed it. It was (probably) caused by outdated assemblies in the Bin folder used by the WDP (seems to be a good idea to manually clean that folder from time to time).
I also copied files from "CommonControls\Bin" to the final output (via pre-build event) which is not necessary and causes everything to break (satellite assemblies for translations are automatically copied by MSVC).
While my problem+solution might not be that helpful to others, it's at least a tutorial how to build a re-distributable assembly with some custom-controls out of a bunch of user-controls.
Notes:
All outputs of the custom-control assembly must be merged. Otherwise we will end up with 2 "App_GlobalResources.dll" files (won't work)
It only works with a "Web-site project", not "Web application"
User-controls must use the "CodeFile/Inherit" tags, not the deprecated "CodeBehind" tag (get rid of all those ".designer.cs" files!)
User-controls must have a "ClassName" tag that differs from the control's name (I appended "Internal" and renamed the class(es) in code-behind)
Embedded resources (images, scripts...) are not directly supported in a "Web-site project". I use an additional LIB for that
When i added service reference to my .Net project (right click->Add Service Reference), VS created a folder with the Service name and created bunch of files (listed below). I am not sure which files should be added to the source control so that next time when i upgrade the service reference, i dont end up deleting some files and adding new files. List of files that VS created in the service folder are as below:
ConfigurationService.disco
ConfigurationService.wsdl
ConfigurationService.xsd
ConfigurationService1.xsd
ConfigurationService2.xsd
ConfigurationService1.wsdl
ConfigurationService3.xsd
ConfigurationService4.xsd
configuration91.svcinfo
configuration.svcinfo
Reference.svcmap
Reference.cs
abc.datasource
def.datasource
ghi.datasource
jkl.datasource
mno.datasource
pqr.datasource
usually we add the whole folder with all its files, you can safely do that.
user specific files are not created in that subfolder.
Consider that when you will update the reference some files will be edited and others will not be touched. If some are fully regenerated TFS or the source control system you are using will get the changes, not the deletion and re-add as another file with same name; at least I would expect so and never seen anything different happening.
I am fighting with Xcode 4 workspaces. Currently Xcode 4 wins. Thus, my situation:
I have the workspace with the iOS app project. There is also static library project iOS app depends on in the this workspace.
Solution #1
I try to configure like this:
the app project:
add to target's Build Phases > Link Binary With Library a product (libmystaticlib.a);
set USER_HEADER_SEARCH_PATHS to $(TARGET_BUILD_DIR)/usr/local/include $(DSTROOT)/usr/local/include;
the static library project:
add some header files to target's Build Phases > Copy Headers > Public;
set SKIP_INSTALL to YES.
And important thing: both projects must have configurations named the same. Otherwise, if I have, e.g., configuration named Distribution (Ad Hoc) for the app and Release for the static library, Xcode can't link the app with the library.
With this configuration archiving results to an archive with the application and public headers from static library projects. Of course, I am not able to share *.ipa in this case. :(
Solution #2
I have also tried another configuration:
Xcode preferences:
set source tree for the static library, e.g, ADDITIONS_PROJECT;
the app project:
add to target's Build Phases > Link Binary With Library a product (libmystaticlib.a);
set USER_HEADER_SEARCH_PATHS to $(ADDITIONS_PROJECT)/**;
the static library project:
don't add any header files to Public!;
set SKIP_INSTALL to YES.
I still need to care about configuration names for both projects. But in result I can build and archive successfully. In the result I get archive and I can share *.ipa.
I don't like the second solutions, because in this case I don't get any real advantage of the Xcode 4 workspace. The same effect I can add get, if I add the static lib project inside the app project. Therefore, I think something is wrong with my solution.
Any suggestion how better to link a static libraries?
I also found a solution that works with build and with archive.
In your static library set the Public Headers Folder Path to ../../Headers/YourLib
In your app config set the Header Search Paths to $(BUILT_PRODUCTS_DIR)/../../Headers
In your app you will be able to code #import <YourLib/YourFile.h>
Don't forget the Skip Install = YES option in your static lib.
We've found an answer, finally. Well, kind of. The problem occurred because Xcode 4 places public headers into InstallationBuildProductsLocation folder during build for archive. Apparently, when archiving it sees the headers and tries to put them into archive as well. Changing Public Headers Folder Path of the lib to somewhere outside of InstallationBuildProductsLocation, for example, to $(DSTROOT)/../public_folders and adding this path to Header Search Path solve the problem.
This solution doesn't look very elegant, but for us it seems to be the only option. May be you'll find this useful.
Here is a solution a get from Apple DTS. I don't like it, because it is suggests to use absolute path. But I still publish it here, maybe someone feels it is right for him.
How to set up the static library:
Add a build configuration named "Archive" by copying the Release Configuration.
Move your headers to the Project group of the Copy Headers build phase.
Set the Per-configuration Build Products Path of the "Archive" configuration to $(BUILD_DIR)/MyLibBuildDir. Xcode will create the MyLibBuildDir folder inside the BuildProductsPath, then add your static library into that folder. You can use "MyLibBuildDir" or provide another name for the above folder.
Set Skip Install to YES for all configurations.
Set Installation Directory of "Archive" to $(TARGET_TEMP_DIR)/UninstalledProducts.
Edit its scheme, set the Build Configuration of its Archive action to "Archive."
How to set up the project linking against the library:
Add a build configuration named "Archive" by copying the Release Configuration.
Set the Library Search Paths of "Archive" to $(BUILD_DIR)/MyLibBuildDir.
Set the User Header Search Paths to the recursive absolute path of your root of your workspace directory for all configurations.
Set Always Search User Paths of "Archive" to YES.
Set Skip_Install to NO for all configurations.
Edit its scheme, set the Build Configuration of its Archive action to "Archive."
I was not real happy with any of the other solutions that were provided, so I found another solution that I prefer. Rather than having to use relevant paths to put the /usr/local/include folder outside of the installation directory, I added a pre-action to the Archive step in my scheme. In the pre-action I provided a script that removed the usr directory prior to archiving.
rm -r "$OBJROOT/ArchiveIntermediates/MyAppName/InstallationBuildProductsLocation/usr"
This removes the usr directory before archiving so that it does not end up in the bundle and cause Xcode to think it has multiple modules.
so far I also struggled with the same problem, but did come to a solution with a minimal tradeoff:
This requires Dervied Data to be your Build Location.
I set the Public Headers Folder path to ../usr/local/include
This will ensure, that the headers will not be placed into the archive.
For the app, I set the Header Search Path to:
$(OBJROOT)/usr/local/include
$(SYMROOT)/usr/local/include
There are 2 entries necessary since the paths slightly change when building an archive and I haven't figured out how to describe it with only one variable.
The nice thing here is, that it doesn't break code sense. So except for having 2 entries rather than one, this works perfectly fine.
I'm struggling with the same problem at the moment. I didn't progress much farther than you. I can only add that in the second solution you can drag headers you need to use from the library to the app project, instead of setting ADDITIONS_PROJECT and USER_HEADER_SEARCH_PATH. This will make them visible in app project. Value of SKIP_INSTALL flag doesn't matter in this case.
Still, this solution isn't going to work for me, because I'm moving rather big project, with dozens of libraries, from Xcode 3 to Xcode 4, and it means really a lot of drag and drop to make my project build and archive correctly. Please let us know if you find any better way out of this situation.
I could use Core Plot as a static library and workspace sibling, with two build configurations:
Release:
in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"
in CorePlot-CocoaTouch, Public Headers Folder Path: /usr/local/include
AdHoc (build configuration for "Archive" step in Scheme, produces a shareable .ipa):
in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"/../../public_folders/**
in CorePlot-CocoaTouch, Public Headers Folder Path: ../../public_folders
Hope it will help someone to not waste a day on this.
I have an ASP.NET 3.5 Website (visual studio lingo), but the site continues to grow and is looking rather cowboyish among other things. I'd like to see this get converted into a Web Application (namespaces and all).
Is this something that can be easily done in Visual Studio? If not, are there any other tools out there that could create all of the namespaces, etc. automagically?
Well, it turns out that the option "Convert to web application" does NOT exist for "websites". The option "Convert to web application" does exist only for "web applications" !!!!
[emphasis mine]
So, here's the deal, to do the
conversion, you need to:
Add a new "Web Application" to your VS 2008 solution (File->Add->New
Project->C#->Web->ASP.NET Web
Application).
Afterwards, you copy all the files in the old "website" to your newly
created "web application", and
override any files created in it by
default
The next step is the most ugly, you need to "manually" add the references
in your "website" to the new "web
application". I thought the VS 2008
PowerCommands toy would do this for me
as it does copy references from other
project types, but it didn't. You have
to do it by yourself, manually, and
you have to be cautious in this step
if you have multiple versions of the
same assembly (like AJAXToolkit in my
case) or assemblies that have both GAC
and local versions or so.
Keep repeating the last step and trying to build the "web application".
You'll keep getting errors like "
'....' is unknown namespace. Are you
missing an assembly reference? ". Make
sure you have none of those except the
ones where '....' is replaced by the
IDs of the server controls you use. In
other words, keep adding references
and building the project until only
the errors that exist because of
missing .DESIGNER.CS or .DESIGNER.VB
files.
Afterwards, go to the "web application" root project node in VS
2008 solution explorer, and right
click it, then you WILL find the
option "Convert to web application".
What this option does is actually
making small changes to the "#Page"
and "#Control" directives of pages and
controls, and creating the required
.DESIGNER.CS or .DESIGNER.VB files.
Try building the "web application" again. If you get errors, see what
references may be missing and/or go
click the "Convert to web application"
again. Sometimes, if there's any error
other than those caused of missing
DESIGNER files, not all the
pages/controls will have those
DESIGNER files created for them.
Fixing the non DESIGNER problem and
clicking "Convert to web application"
again should do the job for this.
Once you are done successful VS build, you should be ready to go.
Start testing your web application.
Optionally, you can right click the
"web application" root project node in
VS 2008 Solution Explorer and click
"Properties" then go to the tab "Web"
to set the "web application" to a
virtual folder in IIS (you can create
new virtual directory from there in
VS). If you want to use the IIS
virtual directory that the old
"website" used, you need to remove
that from IIS first.
Update: When testing your pages, pay MOST ATTENTION to classes in
"App_Code" folder, especially those
with NO NAMESPACE. Those can be a big
trap. We had a problem with two
extension method overloads in the same
static class that had no namespace,one
extends DateTime? (Nullable)
and calls another overload that
extends DateTime itself. Calling the
other overload as extension method
passed VS 2008 compilation and gave us
a compilation error ONLY IN RUNTIME
(With IIS). Changing the call to the
other overload from calling it as
extension method to calling it as
normal static method (only changing
the call in the same class, calls from
other classes remained extension
method calls) did solve this one, but
clearly, it's not as safe as it used
to be in VS 2005. Especially with
classes with no namespaces.
Update2: During the conversion, VS 2008 renames your "App_Code" to
"Old_App_Code". This new name sounds
ugly, but DO NOT RENAME IT BACK. In
the "web application" model, all code
will be in one assembly. In runtime,
the web server does not know what web
project type you are using. It does
take all code in "App_Code" folder and
create a new assembly for it. This
way, if you have code in folder named
"App_Code", you'll end up with RUNTIME
compilation errors that the same types
exist in two assemblies, the one
created by VS, and the one created by
IIS / ASP.NET Development Server. To
avoid that. leave the "Old_App_Code"
with the same name, or rename it to
ANYTHING EXCEPT: "App_Code". Do not
place any code in such "App_Code"
folder and prefereably do NOT have a
folder with such name in your "web
application" at all.
I know this since before but forgot it
now as I have not used "website" model
for long :(.
Walkthrough: Converting a Web Site Project to a Web Application Project in Visual Studio at MSDN
If your website application grows.. it's better to split it into several projects. Conversion from Web Site project to Web Application project won't help much.
If you're having problems getting your new Web Application Project to build check the File Properties in Visual Studio of all 'helper' classes. For a project I was converting the Build Action was set to Content whereas it should have been Compile.
I've now successfully migrated one Website project to a web application and there is quiet a few gotchas to look out for.
Having ReSharper at your disposal helps a lot in refactoring the aspx files.
Set up your solution and create an empty WebApplication
Copy all file over
aspx files in website projects don't have a namspace. Wrap your classes in the appropriate namespaces
During copying, all my pages in subfolders got renamed to my project name and the foldername, so I got 40ish public partial class FolderName_Projectname : Page If neccessary rename all files using Resharper or manually.
If you encounter multiple errors like "There is already a member Page_Load() defined", this is most likely due to incorrect class names und duplication
After adding a namespace
Replace CodeFile in all aspx pages with Codebehind and especially pay attention to files i your subfolder. Make sure Inhertis="" doesn't contain the relative path. Your namespaces take care of everything. So the correct format is Inherits="Namespace.classname".
If your class has a namespace NaSpa and a filename foo.cs it would be Inherits="NaSpa.foo"
After you have prepared all your files (don't forget your master pages), run "Convert to web application". If you encounter errors afterwards, rinse and repeat.
If you encounter errors of the sort "TextBoxName can't be found are you missing a reference", make sure you did not forget to sanitize your aspx pages. A good indicator is to check the automatically generated designer files. If TextBoxName does not appear in there, the conversion did not succeed completely.
Resolve any missing dependencies.
Build
Create a New Web Application in VS 2010.
1. Using Windows Explorer copy all your files into you project folder.
2. In VS 2010 solution explorer show all files.
3. Select the files and folders - right click include in project.
4. Right click the project solution explorer and select Convert to Web Application.
There are quite a few small differences, such as the App_Code folder will get renamed to old_app_code - that surprisingly doesn't cause any errors. The TypeName on your object data sources and the inherits on the #Page tag might need the [ProjectName]. prefix appended globally. For example if your type name was "BusinessLogic.OrderManager" and your project name is InventorySystem you would need to change it to InventorySystem.BusinessLogic.OrderManager. Also a few display changes, such as required field validators don't default to red font anymore, they default to black.
I was facing the same problems initially. After following the Wrox Professional ASP.NET 4.0 book, I found the following solution for my case.
I first created a new web application. Copied all the website files into the web application folder. Right click on the application, and click conver to web application.
You might ask why you need to convert a web app into a web app. The answer is, that when you create a website, you simply code the .cs file where-ever required.
A web application, however declares .design.cs (or .vb) and a .cs file for the code and design section automatically.
NEXT: Remove all manual references, like 'Inherits' attribute in the PAGE directive, to other files in your website, since name spaces WILL take care of referencing the classes centrally.
I also faced a problem, since I had not included OBJ and BIN folder in my project.
If you think you are missing your BIN and OBJ folders, simply click the 'Show All Files' icon in the Solution Explorer and then right click on the missing folders and add to project. (to make sure they compile with the project.)
UPDATE:
As #deadlychambers points out in the comments: You can search everywhere by doing a "Ctrl + Shift + F" and then search for Inherits="(.*?)". This will find all occurrences and probably save you some time!
the default ASP name space does not seem to work anymore. So I cannot seem to call my User Controls.ascx pages from outside the page. Giving them a namespace and changing the default from ASP to my namespace seemed to work.